IBIS Macromodel Task Group

Meeting date: 16 May 2023

Members (asterisk for those attending):
Achronix Semiconductor:       Hansel Dsilva
Amazon:                       John Yan
ANSYS:                      * Curtis Clark
                            * Wei-hsing Huang
Aurora Systems:               Dian Yang
Cadence Design Systems:     * Ambrish Varma
                            * Jared James
Google:                       Hanfeng Wang
                              GaWon Kim
Intel:                      * Michael Mirmak
                              Kinger Cai
                            * Chi-te Chen
                              Liwei Zhao
Keysight Technologies:        Fangyi Rao
                              Majid Ahadi Dolatsara
                              Stephen Slater
                              Ming Yan
                              Rui Yang
Marvell:                      Steve Parker
Mathworks (SiSoft):         * Walter Katz
                            * Graham Kus
Micron Technology:            Justin Butterfield
Missouri S&T:                 Chulsoon Hwang
                              Yifan Ding
                              Zhiping Yang
Rivos:                        Yansheng Wang
SAE ITC:                      Michael McNair
Siemens EDA (Mentor):       * Arpad Muranyi
                            * Randy Wolff
Teraspeed Labs:             * Bob Ross
Zuken USA:                  * Lance Wang

The meeting was led by Arpad Muranyi.  Curtis Clark took the minutes.

--------------------------------------------------------------------------------
Opens:

- None.

-------------
Review of ARs:

Arpad:  Send an email announcing the straw poll ATM vote on whether to include
        SPIM in the IBIS specification itself or make it a stand-alone
        specification.
        - Done.

--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Arpad asked for any comments or corrections to the minutes of the May 9th
meeting.  Michael moved to approve the minutes.  Graham seconded the motion.
There were no objections.

--------------
New Discussion:

Agenda Item 8: Multi-level analog buffer modeling
Arpad noted that he had introduced this discussion topic.  He said there seemed
to be no immediate need to do anything about it.  Arpad moved to table it.
Walter seconded.  There were no objections.

SPIM (BIRD223) in IBIS or as a separate document/specification:
Arpad opened the discussion and asked for comments in advance of the scheduled
straw poll.  Michael asked if there was some particular reason we would want to
separate SPIM from IBIS.  He said that he had the impression that SPIM was of
interest to anyone wanting to do power-aware analysis.  Why would we need to
make it a separate document?

Walter said that there are many different types of models for PI and different
techniques for PI analysis.  He asked whether we were going to include all of
them in the IBIS specification, or whether we are sure that SPIM is the right
one.  If we agree that it's the right one, then go ahead and put it in the IBIS
specification.  Walter said that we had thus far only heard from a couple of
organizations in favor of SPIM.  Ambrish said that his organization was also in
favor of SPIM.  Walter said he had no objection if EDA companies who do PI agree
that SPIM is a good way to do it.

Arpad agreed that there are different ways to handle PI.  He said his question
revolved around the word "technique".  He said he thought we should be careful
to focus on what goes into the model, not on telling EDA tools how to use the
model.  He noted Walter's example of Touchstone as an independent specification
that IBIS utilized.  He said Touchstone models could be useful for SI and PI
modeling, but he noted that Touchstone is a modeling specification that
describes what goes into a model not how an EDA tool should use it.  Arpad
agreed that the AMI sections of IBIS describe simulation flows, which Ambrish
had pointed out as a counter example, but he said he thought IBIS was better off
avoiding flow descriptions.  Walter agreed that it's important to provide the
derivation discussions for what goes into the model itself.  For example, how do
you create the [Model], how do you measure the I/V curve data in a lab or via
simulation with your digital twin model of the device?

Arpad returned to Michael's original question about why we might choose to
separate SPIM from IBIS.  He said one consideration might be logistical.  He
said the IBIS specification is getting rather large, in excess of 400 pages.
It's becoming a bit cumbersome to maintain.  Michael said that together vs.
separate involved a tradeoff between different sets of maintenance headaches,
which were roughly equivalent.  We have some editorial issues adding SPIM to
IBIS and making IBIS larger, but if we keep them separate then we create
different issues with tracking and syncing different versions of the two
documents.

Bob said that he was in favor of integrating SPIM in IBIS.  He acknowledged that
it will make IBIS larger, but he said the syntax is very similar to existing
IBIS syntax.  He said we could simply add a -spim flag and add support for SPIM
to the existing ibischk parser.  He agreed with Michael that tracking two
separate documents has its own set of challenges.  He said SPIM could be added
as a new chapter in IBIS.

Curtis said he thought one practical reason for keeping SPIM inside IBIS is that
we want to get as much feedback on the proposal (BIRD223) as possible.  He said
his concern was that if we decided up front to make SPIM a separate document, we
might be less likely to get careful review and feedback from other
organizations.  Ambrish agreed.  Arpad said this was an interesting point, and
he wondered whether we would have to consider creating a new task group if it
were to be a separate document, e.g., a power integrity task group.

Michael suggested that a separate task group for PI might give the topic the
attention that it deserves.  Graham agreed and said that the variety of topics
and solutions under the umbrella of PI could justify a separate task group.  He
noted that we still tend to talk about SI and PI separately as opposed to
overall system analysis, though he agreed that SI/PI cosimulation can be
important.  He said he had no real preference for whether SPIM was separate or
part of IBIS, but he thought a new PI task group would be useful in either
case.

Arpad said Graham's comments were an interesting way to think about it.  He said
you can do PI on its own without much signal information.  You can also do SI/PI
combined and see how they affect each other, primarily how the power affects the
signal.  He said in IBIS we have power-aware buffer models ([Composite Current],
[ISSO_PU], [ISSO_PD], etc.), and we have Touchstone models, which could be made
for SI and PI separately or could combine both.  So, he wondered if it was a
question of whether we want to keep SI and PI separate.  If we want to combine
them, then it probably makes sense to have SPIM in IBIS.  Ambrish agreed that
the question is whether we want an overall power-aware IBIS model that can be
used for SI/PI.  Arpad and Ambrish agreed that this is probably the goal, and
in that case it would make sense to keep SPIM in IBIS.

Randy said he was torn on the direction we should take.  He thought that we
could make it work either way.  He agreed that making SPIM a separate document
might result in a lack of focus and a loss of feedback.  He agreed that PI is a
big enough topic that it could justify its own task group, but he said it might
be hard to start another weekly meeting.  He said perhaps ATM has the time to
focus on PI issues for now.

Arpad asked if any more discussion was required prior to the straw poll.  Arpad
started the straw poll vote by organization.  The question was whether to keep
on the course of having SPIM be part of the IBIS specification.  The votes were
as follows:

Ansys - Yes
Cadence - Yes
Intel - Yes
Mathworks - Abstain
Siemens EDA - Abstain
Teraspeed - Yes
Zuken - Yes

The total was 5 Yes votes and 2 Abstain votes, and the ATM recommends keeping
SPIM as part of IBIS rather than a separate document.

PSIJ Sensitivity:
Bob noted that a group from India Institute of Technology Jodhpur had given a
presentation on PSIJ in CMOS inverters at the recent IEEE SPI IBIS Summit.
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ibis.org_summits_may23_verma.pdf&d=DwIGAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=DcQR-qLpQg5lIreuM6-NYECRIAFXt268PRNS5WO043M&m=k0Ad7uasXdJEdmanOUk0fMdMhleBBaoXCmkmeHqRe8UT-5jLFZgwHO3rk-UsI5zp&s=ODQoXvI4QvU0i22brrHsGAA-V7gKufs9qS5JpmaQu_A&e= 

Bob said that their presentation was not related to Kinger's PSIJ Sensitivity
proposal and did not discuss the existing BIRD220 "Pre-driver PSIJ Sensitivity
Keyword".  However, Bob said he had forwarded the group information on both
PSIJ proposals to see if they were interested in commenting.

- Michael: Motion to adjourn.
- Ambrish: Second.
- Arpad: Thank you all for joining.

New ARs:

Arpad:  Send an email announcing the ATM task group's recommendation that SPIM
        continue on the track toward being included in IBIS.

-------------
Next meeting: 23 May 2023 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
